God is a mock. – Just Kidding

目录 Table of Contents

背景

最近接到了新任务——希望 mock 掉项目依赖的底座，主要基于两点考量：

• 内部联调时可以屏蔽掉底座的影响，不至于阻塞当前开发模块的流程；
• 之后可集成自动化测试，降低测试成本。

我的第一感觉是这个东西不好搞。一是上下游的依赖关系比较复杂，这意味着：首先让 mock 做到可以替换原来的底座以满足基本功能就需要一些努力，其次项目“看起来”运行正常并不能保证上游亦是如此；二是替换底座包含了 mock 掉数据返回和状态管理两个概念，那么就不得不在简洁和可用之间做取舍了。

前文已经展开讨论了业务分析和架构演化这两方面的内容，本文将整理一些技术细节。

技术选型

Postman

• 优点：
  1. 界面化操作，比较直观
  2. 可以集成 Postman 各种功能，如接口文档、接口测试等
• 缺点：
  1. 设置匹配规则不够灵活
  2. 返回数据自定义不方便
  3. 所有用例都在一个文件，不好进行版本管理

web framework

• 优点：
  1. 由于是自己来实现功能，非常灵活
• 缺点：
  1. 重新造很多轮子，工作量大

json-server + Mock.js

• 优点：
  1. 框架轻量且容易上手
  2. json-server用于设置转发规则，mock.js用于模拟返回数据，分工明确
• 缺点：
  1. 二次开发有语言壁垒

内部框架

• 优点：
  1. 转发规则和返回数据在同一模板文件中约定
  2. 内置了常用的工具函数，并且支持存根注入来扩展功能
  3. 非单一的 mock 框架，支持契约测试
• 缺点：
  1. 存根入口单一，复用存根不太方便
  2. 请求参数匹配支持较弱

总结：选用内部框架更符合当前的场景。

接口文档 / 接口测试

Postman + Newman

• 优点：
  • 界面化操作，比较直观
  • 独立于代码之外，无侵入
  • 接口测试比较强大，支持设置顺序、次数、运行测试前执行脚本和运行测试后进行判断等功能
• 缺点：
  • 生成的接口文档只能在线查看，无法本地保存
  • 文档可定制化的部分较少，无法对输入输出字段做备注

Swagger

• 优点：
  • 生成的文档信息齐全，包括路径、请求参数及描述、返回数据及描述以及示例等
  • 直接在代码中标记，可以培养一边开发一边写文档的好习惯
  • 配置后还可以直接发送请求测试接口
• 缺点：
  • 接口测试功能比较单一，无法很方便地管理一个功能集合层面的测试用例

总结：如果看重文档输出，使用 Swagger；如果看重接口测试，使用 Postman + Newman。如果是在开发过程中，使用 Swagger，持续集成；如果是在开发过程后，使用 Postman + Newman，最少改动。其实最佳实践应该是两者结合起来使用，唯一的缺点就是工作量比较大。

进程部署 / 容器部署

• 分别提供两种模式的部署脚本，前置知识：

  • #Linux&Shell# 速查手册：常用 Linux&Shell 命令
  • #Docker# 速查手册：常用 Docker 命令
  • #Kubernetes# 速查手册：常用 Kubernetes 命令

代办事项

• 完善单元测试
• 精简镜像大小
• 接入 CI / CD 流水线

附录

• 聊一聊契约测试